At tæmme bæstet: Refactoring-strategier for legacy-kode

Legacy-kode. Selve begrebet fremmaner ofte billeder af vidtstrakte, udokumenterede systemer, skrøbelige afhængigheder og en overvældende følelse af frygt. Mange udviklere verden over står over for udfordringen med at vedligeholde og udvikle disse systemer, som ofte er kritiske for forretningsdriften. Denne omfattende guide giver praktiske strategier til refactoring af legacy-kode, så en kilde til frustration kan blive en mulighed for modernisering og forbedring.

Hvad er legacy-kode?

Før vi dykker ned i refactoring-teknikker, er det vigtigt at definere, hvad vi mener med "legacy-kode". Selvom udtrykket blot kan henvise til ældre kode, fokuserer en mere nuanceret definition på dens vedligeholdelighed. Michael Feathers definerer i sin banebrydende bog "Working Effectively with Legacy Code" legacy-kode som kode uden tests. Denne mangel på tests gør det svært at ændre koden sikkert uden at introducere regressioner. Legacy-kode kan dog også have andre kendetegn:

• Mangel på dokumentation: De oprindelige udviklere er måske stoppet og har efterladt lidt eller ingen dokumentation, der forklarer systemets arkitektur, designbeslutninger eller endda grundlæggende funktionalitet.
• Komplekse afhængigheder: Koden kan være tæt koblet, hvilket gør det svært at isolere og ændre individuelle komponenter uden at påvirke andre dele af systemet.
• Forældede teknologier: Koden kan være skrevet i ældre programmeringssprog, frameworks eller biblioteker, der ikke længere aktivt understøttes, hvilket udgør sikkerhedsrisici og begrænser adgangen til moderne værktøjer.
• Dårlig kodekvalitet: Koden kan indeholde duplikeret kode, lange metoder og andre "code smells", der gør den svær at forstå og vedligeholde.
• Skrøbeligt design: Tilsyneladende små ændringer kan have uforudsete og vidtrækkende konsekvenser.

Det er vigtigt at bemærke, at legacy-kode ikke i sig selv er dårlig. Den repræsenterer ofte en betydelig investering og indeholder værdifuld domæneviden. Målet med refactoring er at bevare denne værdi, samtidig med at man forbedrer kodens vedligeholdelighed, pålidelighed og ydeevne.

Hvorfor refactorere legacy-kode?

Refactoring af legacy-kode kan være en skræmmende opgave, men fordelene opvejer ofte udfordringerne. Her er nogle af de vigtigste grunde til at investere i refactoring:

• Forbedret vedligeholdelighed: Refactoring gør koden lettere at forstå, ændre og fejlfinde i, hvilket reducerer omkostningerne og indsatsen, der kræves til løbende vedligeholdelse. For globale teams er dette særligt vigtigt, da det reducerer afhængigheden af specifikke personer og fremmer videndeling.
• Reduceret teknisk gæld: Teknisk gæld henviser til de implicitte omkostninger ved omarbejde, der skyldes, at man vælger en nem løsning nu i stedet for at bruge en bedre tilgang, der ville tage længere tid. Refactoring hjælper med at afdrage på denne gæld og forbedrer kodebasens generelle sundhed.
• Forbedret pålidelighed: Ved at adressere "code smells" og forbedre kodens struktur kan refactoring reducere risikoen for fejl og forbedre systemets generelle pålidelighed.
• Øget ydeevne: Refactoring kan identificere og løse ydelsesmæssige flaskehalse, hvilket resulterer i hurtigere eksekveringstider og forbedret responsivitet.
• Nemmere integration: Refactoring kan gøre det lettere at integrere legacy-systemet med nye systemer og teknologier, hvilket muliggør innovation og modernisering. For eksempel kan en europæisk e-handelsplatform have brug for at integrere med en ny betalingsgateway, der bruger et andet API.
• Forbedret udviklermoral: At arbejde med ren, velstruktureret kode er sjovere og mere produktivt for udviklere. Refactoring kan øge moralen og tiltrække talenter.

Identifikation af refactoring-kandidater

Ikke al legacy-kode behøver at blive refactoreret. Det er vigtigt at prioritere refactoring-indsatsen baseret på følgende faktorer:

• Ændringshyppighed: Kode, der ofte ændres, er en oplagt kandidat til refactoring, da forbedringer i vedligeholdeligheden vil have en betydelig indvirkning på udviklingsproduktiviteten.
• Kompleksitet: Kode, der er kompleks og svær at forstå, er mere tilbøjelig til at indeholde fejl og er sværere at ændre sikkert.
• Konsekvens af fejl: Kode, der er kritisk for forretningsdriften, eller som har en høj risiko for at forårsage dyre fejl, bør prioriteres til refactoring.
• Ydelsesmæssige flaskehalse: Kode, der identificeres som en ydelsesmæssig flaskehals, bør refactoreres for at forbedre ydeevnen.
• Code Smells: Hold øje med almindelige "code smells" som lange metoder, store klasser, duplikeret kode og "feature envy". Disse er indikatorer på områder, der kan have gavn af refactoring.

Eksempel: Forestil dig et globalt logistikfirma med et legacy-system til at håndtere forsendelser. Modulet, der er ansvarligt for at beregne forsendelsesomkostninger, opdateres ofte på grund af ændrede regler og brændstofpriser. Dette modul er en oplagt kandidat til refactoring.

Refactoring-teknikker

Der findes mange refactoring-teknikker, som hver især er designet til at adressere specifikke "code smells" eller forbedre bestemte aspekter af koden. Her er nogle almindeligt anvendte teknikker:

Sammensætning af metoder

Disse teknikker fokuserer på at nedbryde store, komplekse metoder til mindre, mere håndterbare metoder. Dette forbedrer læsbarheden, reducerer duplikering og gør koden lettere at teste.

• Extract Method: Dette indebærer at identificere en kodeblok, der udfører en specifik opgave, og flytte den til en ny metode.
• Inline Method: Dette indebærer at erstatte et metodekald med metodens krop. Brug dette, når en metodes navn er lige så klart som dens krop, eller når du er ved at bruge Extract Method, men den eksisterende metode er for kort.
• Replace Temp with Query: Dette indebærer at erstatte en midlertidig variabel med et metodekald, der beregner variablens værdi efter behov.
• Introduce Explaining Variable: Brug dette til at tildele resultatet af et udtryk til en variabel med et beskrivende navn, hvilket tydeliggør dens formål.

Flytning af features mellem objekter

Disse teknikker fokuserer på at forbedre designet af klasser og objekter ved at flytte ansvarsområder derhen, hvor de hører til.

• Move Method: Dette indebærer at flytte en metode fra en klasse til en anden klasse, hvor den logisk set hører til.
• Move Field: Dette indebærer at flytte et felt fra en klasse til en anden klasse, hvor det logisk set hører til.
• Extract Class: Dette indebærer at oprette en ny klasse fra et sammenhængende sæt af ansvarsområder, der er udtrukket fra en eksisterende klasse.
• Inline Class: Brug dette til at kollapse en klasse ind i en anden, når den ikke længere gør nok til at retfærdiggøre sin eksistens.
• Hide Delegate: Dette indebærer at oprette metoder i serveren for at skjule delegeringslogik fra klienten, hvilket reducerer koblingen mellem klienten og delegaten.
• Remove Middle Man: Hvis en klasse delegerer næsten alt sit arbejde, hjælper dette med at fjerne mellemmanden.
• Introduce Foreign Method: Tilføjer en metode til en klientklasse for at servicere klienten med features, der reelt er nødvendige fra en serverklasse, men som ikke kan ændres på grund af manglende adgang eller planlagte ændringer i serverklassen.
• Introduce Local Extension: Opretter en ny klasse, der indeholder de nye metoder. Nyttigt, når du ikke har kontrol over kilden til klassen og ikke kan tilføje adfærd direkte.

Organisering af data

Disse teknikker fokuserer på at forbedre måden, data lagres og tilgås på, hvilket gør det lettere at forstå og ændre.

• Replace Data Value with Object: Dette indebærer at erstatte en simpel dataværdi med et objekt, der indkapsler relaterede data og adfærd.
• Change Value to Reference: Dette indebærer at ændre et værdi-objekt til et reference-objekt, når flere objekter deler den samme værdi.
• Change Unidirectional Association to Bidirectional: Opretter en tovejsforbindelse mellem to klasser, hvor der kun eksisterer en envejsforbindelse.
• Change Bidirectional Association to Unidirectional: Forenkler associationer ved at gøre et tovejsforhold til envejs.
• Replace Magic Number with Symbolic Constant: Dette indebærer at erstatte bogstavelige værdier med navngivne konstanter, hvilket gør koden lettere at forstå og vedligeholde.
• Encapsulate Field: Tilvejebringer en getter- og setter-metode for at få adgang til feltet.
• Encapsulate Collection: Sikrer, at alle ændringer i samlingen sker gennem omhyggeligt kontrollerede metoder i ejerklassen.
• Replace Record with Data Class: Opretter en ny klasse med felter, der matcher recordens struktur, og accessor-metoder.
• Replace Type Code with Class: Opret en ny klasse, når typekoden har et begrænset, kendt sæt af mulige værdier.
• Replace Type Code with Subclasses: Til når typekodens værdi påvirker klassens adfærd.
• Replace Type Code with State/Strategy: Til når typekodens værdi påvirker klassens adfærd, men subklasser ikke er passende.
• Replace Subclass with Fields: Fjerner en subklasse og tilføjer felter til superklassen, der repræsenterer subklassens distinkte egenskaber.

Forenkling af betingede udtryk

Betinget logik kan hurtigt blive indviklet. Disse teknikker sigter mod at tydeliggøre og forenkle.

• Decompose Conditional: Dette indebærer at nedbryde et komplekst betinget udtryk i mindre, mere håndterbare stykker.
• Consolidate Conditional Expression: Dette indebærer at kombinere flere betingede udtryk til et enkelt, mere præcist udtryk.
• Consolidate Duplicate Conditional Fragments: Dette indebærer at flytte kode, der er duplikeret i flere grene af et betinget udtryk, uden for betingelsen.
• Remove Control Flag: Eliminer boolske variable, der bruges til at kontrollere logikflowet.
• Replace Nested Conditional with Guard Clauses: Gør koden mere læsbar ved at placere alle specialtilfælde øverst og stoppe behandlingen, hvis nogen af dem er sande.
• Replace Conditional with Polymorphism: Dette indebærer at erstatte betinget logik med polymorfi, hvilket giver forskellige objekter mulighed for at håndtere forskellige tilfælde.
• Introduce Null Object: I stedet for at tjekke for en null-værdi, opret et standardobjekt, der giver standardadfærd.
• Introduce Assertion: Dokumenter eksplicit forventninger ved at oprette en test, der tjekker for dem.

Forenkling af metodekald

• Rename Method: Dette virker indlysende, men er utroligt nyttigt til at gøre koden klar.
• Add Parameter: At tilføje information til en metodesignatur giver metoden mulighed for at være mere fleksibel og genanvendelig.
• Remove Parameter: Hvis en parameter ikke bruges, skal den fjernes for at forenkle grænsefladen.
• Separate Query from Modifier: Hvis en metode både ændrer og returnerer en værdi, skal den adskilles i to distinkte metoder.
• Parameterize Method: Brug dette til at konsolidere lignende metoder til en enkelt metode med en parameter, der varierer adfærden.
• Replace Parameter with Explicit Methods: Gør det modsatte af at parameterisere - opdel en enkelt metode i flere metoder, der hver især repræsenterer en specifik værdi af parameteren.
• Preserve Whole Object: I stedet for at sende et par specifikke dataelementer til en metode, send hele objektet, så metoden har adgang til alle dens data.
• Replace Parameter with Method: Hvis en metode altid kaldes med den samme værdi, der stammer fra et felt, kan du overveje at udlede parameterværdien inde i metoden.
• Introduce Parameter Object: Grupper flere parametre sammen i et objekt, når de naturligt hører sammen.
• Remove Setting Method: Undgå settere, hvis et felt kun skal initialiseres, men ikke ændres efter konstruktion.
• Hide Method: Reducer synligheden af en metode, hvis den kun bruges inden for en enkelt klasse.
• Replace Constructor with Factory Method: Et mere beskrivende alternativ til konstruktører.
• Replace Exception with Test: Hvis undtagelser bruges som flowkontrol, skal de erstattes med betinget logik for at forbedre ydeevnen.

Håndtering af generalisering

• Pull Up Field: Flyt et felt fra en subklasse til dens superklasse.
• Pull Up Method: Flyt en metode fra en subklasse til dens superklasse.
• Pull Up Constructor Body: Flyt kroppen af en konstruktør fra en subklasse til dens superklasse.
• Push Down Method: Flyt en metode fra en superklasse til dens subklasser.
• Push Down Field: Flyt et felt fra en superklasse til dens subklasser.
• Extract Interface: Opretter en grænseflade fra de offentlige metoder i en klasse.
• Extract Superclass: Flyt fælles funktionalitet fra to klasser til en ny superklasse.
• Collapse Hierarchy: Kombiner en superklasse og subklasse til en enkelt klasse.
• Form Template Method: Opret en skabelonmetode i en superklasse, der definerer trinnene i en algoritme, så subklasser kan tilsidesætte specifikke trin.
• Replace Inheritance with Delegation: Opret et felt i klassen, der refererer til funktionaliteten, i stedet for at arve den.
• Replace Delegation with Inheritance: Når delegering er for kompleks, skift til arv.

Dette er blot nogle få eksempler på de mange refactoring-teknikker, der er tilgængelige. Valget af, hvilken teknik man skal bruge, afhænger af den specifikke "code smell" og det ønskede resultat.

Eksempel: En stor metode i en Java-applikation, der bruges af en global bank, beregner rentesatser. Anvendelse af Extract Method til at skabe mindre, mere fokuserede metoder forbedrer læsbarheden og gør det lettere at opdatere rentesatsberegningslogikken uden at påvirke andre dele af metoden.

Refactoring-processen

Refactoring bør tilgås systematisk for at minimere risikoen og maksimere chancerne for succes. Her er en anbefalet proces:

1. Identificer refactoring-kandidater: Brug de tidligere nævnte kriterier til at identificere områder af koden, der vil have mest gavn af refactoring.
2. Opret tests: Før du foretager ændringer, skal du skrive automatiserede tests for at verificere den eksisterende adfærd af koden. Dette er afgørende for at sikre, at refactoring ikke introducerer regressioner. Værktøjer som JUnit (Java), pytest (Python) eller Jest (JavaScript) kan bruges til at skrive enhedstests.
3. Refactorer inkrementelt: Foretag små, inkrementelle ændringer, og kør testene efter hver ændring. Dette gør det lettere at identificere og rette eventuelle fejl, der introduceres.
4. Commit ofte: Commit dine ændringer til versionskontrol ofte. Dette giver dig mulighed for let at vende tilbage til en tidligere version, hvis noget går galt.
5. Gennemgå koden: Få din kode gennemgået af en anden udvikler. Dette kan hjælpe med at identificere potentielle problemer og sikre, at refactoring udføres korrekt.
6. Overvåg ydeevnen: Efter refactoring skal du overvåge systemets ydeevne for at sikre, at ændringerne ikke har introduceret nogen ydelsesmæssige regressioner.

Eksempel: Et team, der refactorerer et Python-modul i en global e-handelsplatform, bruger `pytest` til at oprette enhedstests for den eksisterende funktionalitet. De anvender derefter Extract Class refactoring for at adskille ansvarsområder og forbedre modulets struktur. Efter hver lille ændring kører de testene for at sikre, at funktionaliteten forbliver uændret.

Strategier for at introducere tests i legacy-kode

Som Michael Feathers rammende sagde, er legacy-kode kode uden tests. At introducere tests i eksisterende kodebaser kan føles som en massiv opgave, men det er afgørende for sikker refactoring. Her er flere strategier til at gribe denne opgave an:

Karakteriseringstests (også kendt som Golden Master Tests)

Når du har at gøre med kode, der er svær at forstå, kan karakteriseringstests hjælpe dig med at fange dens eksisterende adfærd, før du begynder at foretage ændringer. Ideen er at skrive tests, der fastslår den nuværende output af koden for et givet sæt inputs. Disse tests verificerer ikke nødvendigvis korrektheden; de dokumenterer simpelthen, hvad koden *i øjeblikket* gør.

Trin:

1. Identificer en enhed af kode, du vil karakterisere (f.eks. en funktion eller metode).
2. Opret et sæt inputværdier, der repræsenterer en række almindelige og edge-case scenarier.
3. Kør koden med disse inputs og fang de resulterende outputs.
4. Skriv tests, der fastslår, at koden producerer præcis disse outputs for disse inputs.

Advarsel: Karakteriseringstests kan være skrøbelige, hvis den underliggende logik er kompleks eller dataafhængig. Vær forberedt på at opdatere dem, hvis du senere skal ændre kodens adfærd.

Sprout Method og Sprout Class

Disse teknikker, også beskrevet af Michael Feathers, sigter mod at introducere ny funktionalitet i et legacy-system og samtidig minimere risikoen for at ødelægge eksisterende kode.

Sprout Method: Når du skal tilføje en ny feature, der kræver ændring af en eksisterende metode, skal du oprette en ny metode, der indeholder den nye logik. Kald derefter denne nye metode fra den eksisterende metode. Dette giver dig mulighed for at isolere den nye kode og teste den uafhængigt.

Sprout Class: Ligner Sprout Method, men for klasser. Opret en ny klasse, der implementerer den nye funktionalitet, og integrer den derefter i det eksisterende system.

Sandboxing

Sandboxing indebærer at isolere legacy-koden fra resten af systemet, så du kan teste den i et kontrolleret miljø. Dette kan gøres ved at oprette mocks eller stubs for afhængigheder eller ved at køre koden i en virtuel maskine.

Mikado-metoden

Mikado-metoden er en visuel problemløsningstilgang til at tackle komplekse refactoring-opgaver. Det indebærer at oprette et diagram, der repræsenterer afhængighederne mellem forskellige dele af koden og derefter refactorere koden på en måde, der minimerer indvirkningen på andre dele af systemet. Kerneprincippet er at "prøve" ændringen og se, hvad der går i stykker. Hvis det går i stykker, skal du vende tilbage til den sidste fungerende tilstand og registrere problemet. Løs derefter det problem, før du igen forsøger den oprindelige ændring.

Værktøjer til refactoring

Flere værktøjer kan hjælpe med refactoring, automatisere gentagne opgaver og give vejledning om bedste praksis. Disse værktøjer er ofte integreret i Integrated Development Environments (IDE'er):

• IDE'er (f.eks. IntelliJ IDEA, Eclipse, Visual Studio): IDE'er giver indbyggede refactoring-værktøjer, der automatisk kan udføre opgaver som at omdøbe variable, udtrække metoder og flytte klasser.
• Statiske analyseværktøjer (f.eks. SonarQube, Checkstyle, PMD): Disse værktøjer analyserer kode for "code smells", potentielle fejl og sikkerhedssårbarheder. De kan hjælpe med at identificere områder af koden, der ville have gavn af refactoring.
• Kodedækningsværktøjer (f.eks. JaCoCo, Cobertura): Disse værktøjer måler den procentdel af koden, der er dækket af tests. De kan hjælpe med at identificere områder af koden, der ikke er tilstrækkeligt testet.
• Refactoring Browsers (f.eks. Smalltalk Refactoring Browser): Specialiserede værktøjer, der hjælper med større omstruktureringsaktiviteter.

Eksempel: Et udviklingsteam, der arbejder på en C#-applikation for et globalt forsikringsselskab, bruger Visual Studios indbyggede refactoring-værktøjer til automatisk at omdøbe variable og udtrække metoder. De bruger også SonarQube til at identificere "code smells" og potentielle sårbarheder.

Udfordringer og risici

Refactoring af legacy-kode er ikke uden udfordringer og risici:

• Introduktion af regressioner: Den største risiko er at introducere fejl under refactoring-processen. Dette kan afhjælpes ved at skrive omfattende tests og refactorere inkrementelt.
• Mangel på domæneviden: Hvis de oprindelige udviklere er stoppet, kan det være svært at forstå koden og dens formål. Dette kan føre til forkerte refactoring-beslutninger.
• Tæt kobling: Tæt koblet kode er sværere at refactorere, da ændringer i en del af koden kan have utilsigtede konsekvenser for andre dele af koden.
• Tidsbegrænsninger: Refactoring kan tage tid, og det kan være svært at retfærdiggøre investeringen over for interessenter, der er fokuseret på at levere nye funktioner.
• Modstand mod forandring: Nogle udviklere kan være modstandsdygtige over for refactoring, især hvis de ikke er bekendt med de involverede teknikker.

Bedste praksis

For at mindske udfordringerne og risiciene forbundet med refactoring af legacy-kode, følg disse bedste praksisser:

• Få opbakning: Sørg for, at interessenter forstår fordelene ved refactoring og er villige til at investere den nødvendige tid og ressourcer.
• Start i det små: Begynd med at refactorere små, isolerede stykker kode. Dette vil hjælpe med at opbygge selvtillid og demonstrere værdien af refactoring.
• Refactorer inkrementelt: Foretag små, inkrementelle ændringer og test ofte. Dette vil gøre det lettere at identificere og rette eventuelle fejl, der introduceres.
• Automatiser tests: Skriv omfattende automatiserede tests for at verificere kodens adfærd før og efter refactoring.
• Brug refactoring-værktøjer: Udnyt de refactoring-værktøjer, der er tilgængelige i dit IDE eller andre værktøjer, til at automatisere gentagne opgaver og give vejledning om bedste praksis.
• Dokumenter dine ændringer: Dokumenter de ændringer, du foretager under refactoring. Dette vil hjælpe andre udviklere med at forstå koden og undgå at introducere regressioner i fremtiden.
• Kontinuerlig refactoring: Gør refactoring til en kontinuerlig del af udviklingsprocessen, snarere end en engangsforeteelse. Dette vil hjælpe med at holde kodebasen ren og vedligeholdelig.

Konklusion

Refactoring af legacy-kode er en udfordrende, men givende bestræbelse. Ved at følge de strategier og bedste praksisser, der er beskrevet i denne guide, kan du tæmme bæstet og omdanne dine legacy-systemer til vedligeholdelige, pålidelige og højtydende aktiver. Husk at gribe refactoring systematisk an, teste ofte og kommunikere effektivt med dit team. Med omhyggelig planlægning og udførelse kan du frigøre det skjulte potentiale i din legacy-kode og bane vejen for fremtidig innovation.